Memory corruption can occur in a computer program when the contents of a memory location are unintentionally modified due to programming errors. When the corrupted memory contents are used later in that program, it leads either to program crash or to unexpected and generally unwanted program behavior.
Memory corruption can be difficult to fix for at least two reasons: 1) The source of the memory corruption and its manifestation may be far apart, making it hard to correlate the cause and the effect. 2) Such errors may only occur under unusual conditions, making it hard to consistently reproduce the error.
When debugging memory corruptions, a common debug approach is to use data address trace to find the previous code locations that wrote to the corrupt memory location. However, data address trace is expensive in terms of performance overhead. In contrast, processor trace provides a relatively compact runtime program control flow trace for a logical CPU thread for debugging, but does not provide data address trace.
Existing hardware debug solutions to the “finding last store to corrupted location” problem need at least address trace or full data trace or even replay support in hardware. However, data address trace is expensive to implement in hardware on fast out-of-order cores; it also has high overhead due to the required bandwidth to log the trace information. Program slicing techniques can identify the corrupting store, but typically need instrumented code and access to the full program flow graph in the compiler. Memory corruption in trivial programs can be solved with program slicing, but this is not the case for more complex programs.